危機管理室の吉本です。

CODE BLUE 2024の以下のセッションについてレポートをまとめます。

PkgFuzzプロジェクト: オープンソースソフトウェアのための新たな継続的ファジング

Googleが2016年に開始したOSS-Fuzzプロジェクトは2023年8月時点でさまざまなソフトウェアのバグを3万6000件以上見つけている。このプロジェクトでは「ファジング」という自動的にソフトウェアのバグを検出する技術が中核として使われている。ファジングは、自動的なバグ検出技術と言われるが、実際にファジングを実施するためにはハーネス（検査対象ソフトウェアを呼び出すプログラム）の作成、ファジング用バイナリの生成、コマンドライン引数の調整、初期シードの準備、などの人手による作業が必要である。特に、異なる複数のソフトウェアをファジングする場合、これらの作業が障害（自動化阻害要因）となり、ファジングワークフロー全体を自動化できない。このため、効率的に多種多様なソフトウェアのファジングを行うことが難しい。

われわれは、これら自動化阻害要因を解消し、ファジング・ワークフロー全体を自動化するシステム、PkgFuzzを開発した。PkzFuzzでは、ソフトウェア・パッケージのビルドプロセスを監視し、ファジング可能なパッケージを選び出す。また、同時にファジングに必要な情報を収集する。このPkgFuzzを利用したファジングキャンペーン、PkgFuzz Projectについて発表する。PkgFuzz Projectでは、多種多様なソフトウェアが含まれるUbuntu 23.10のDebianパッケージに対するファジングキャンペーンを実施したところ、人間の介在なしに、265のパッケージから、6万4658件のクラッシュを得た。これらを精査したところ、攻撃に利用可能な4件の脆弱性を発見した。これらをIPAへ報告し、3件のアドバイザリとCVEの発行へとつなげた。

PkgFuzzがファジングを自動実行した265のパッケージのうち、OSS-Fuzzでもファジングが実施されていたOSSプロジェクトはわずか32件（12％程度）であった。これは、PkgFuzz Projectが、OSS-Fuzzが今までファジング対象としていなかったOSSをファジングできていることを示している。PkgFuzz Projectではファジングの準備を自動化できる。つまり、OSS-Fuzzとは異なり、ハーネスの作成やコマンドライン引数の調整など、OSS開発者によるファジングのためだけの開発コストを要求しないため、ファジング導入のハードルが低い。そのため、今までファジングによるセキュリティテストを導入できていなかったOSSプロジェクト（特に今までOSS-Fuzzの恩恵をあまり受けていない小規模なOSS）に対してもファジングキャンペーンを実施することができる。PkgFuzz Projectにより、バグを発見、修正していくことで、より多くのOSSプロジェクトに対してセキュリティレベルの向上を促進し、安心なソフトウェア基盤の実現を可能にすると考える。

Presented by : Yuhei Kawakoya 川古谷 裕平 Eitaro Shioji 塩治 榮太朗 Yuto Otsuki 大月 勇人

レポート

• PkgFuzzプロジェクトについて紹介する
• 自己紹介
• NTTセキュリティホールディングス
• NTT社会情報研究所
• 脆弱性の価値
  • ゼロデイ脆弱性は高価で取引されている
  • 1億5000万円で取引されたものもある
  • ゼロデイハッキングコンテストの賞金は3000万円のものがある
• どうやって脆弱性を見つけるか
  • ファジング、Reverse Engineering、既知の脆弱性空など
  • 最も多いのがファジング
• ファジングとは
  • 通常ではありえない入力を与えて、異常な振る舞いがないかテストすること
  • 意外と歴史が古く、1990のACMの論文がある
  • 2024年でも研究発表が盛んにされている
• ファジングプロジェクト：Google OSS-Fuzz
  • GoogleのOSSのファジングプロジェクト
  • Googleのクラウド上でファジングが実行できる
  • 参加条件は、それなりにメジャーなOSSプロジェクトであること
  • ファジングの準備に関するところに我々は注目している
• ファジングの自動化阻害要因
  • ファジングのすべてが自動化されているわけではない
  • 1つのソフトだと問題ないが、複数のソフトにファジングしようとすると全体の効率が著しく下がる
  • 自動化阻害要因と呼んでいる
  • 自動化阻害要因の4つのうちNo1とNo4について説明
  • 1．ハーネスの準備
    • ライブラリー関数をファジングする場合、呼び出す必要があるのでハーネスが必要
    • ハーネスの準備が必要になる
  • 4．シードファイルの準備
    • ゼロ知識で適切な入力はできない
    • もとになるデータがあって、入力を調整する
    • この元データをシードファイルと呼ぶ
    • Readmeを呼んでファイルフォーマットを探すなど
    • これも人間の介在が必要になる
• OSS-Fuzzでの対処
  • OSSプロジェクト側がファジングの準備をする
  • 大規模なOSSなら問題ないが、個人や小規模なOSSプロジェクトだと準備の負担が問題になる
  • OSS-Fuzzが今までリーチできなかったOSSプロジェクトに貢献できるのでは
• PkgFuzz（パッケージファズ）
• コアコンセプト
  • ソフトウェアパッケージに注目した
  • Ubuntsuでは、ソフトウェアの配布ができるようになっている
  • ファジングに必要な情報が自動収集できるのでは
  • パッケージに含まれているテストコードを活用する
  • パッケージの仕様によってビルドオプションが共通化されている
  • これらを活用したのがパッケージファズ
• ユーザーは自動的にファジングができる
• Phase1 パッケージ解析
  • パッケージを解析する
  • 例：jbigkit v2 1-6
• Phase2 ファジング
  • 短時間のファジングにより、動かないものや効果が薄いものを除外
  • その後、長期間のファジングを実施
• Phase3 クラッシュトリアージ
  • 大量のクラッシュをトリアージする
  • 分類して重複を排除
  • 簡易的に攻撃に使えるかを判定
  • 元のパッケージのバイナリで再現するかを検証
  • CASRと、AFLトリアージを併用
• CASR
  • 攻撃可能性の高さを評価してくれるのが特徴
  • 高中低の3段階で分類
• パッケージファズプロジェクト
  • Ubuntsuのパッケージを対象に脆弱性調査と性能評価を目的とした
  • エクスプロイトコードの作成などにより検証
  • 条件はバグが残存していそうなもの（C++、ある程度の規模、古い）
  • 短時間ファジングなどでふるいをかけて残ったのが256件
  • 318日間調査した
  • 606回のファジング、1パッケージ当たり2.28回
  • クラッシュ数：64658件をトリアージ
• 分析
  • 174件64.5%、3分の2のパッケージで何かしらのバグが存在
  • 脆弱性が65のパッケージで脆弱性が存在する可能性が高い
  • メモリの読み書きに関係するものが多く435件
  • 書き込みができる時点で脆弱性につながりやすく深刻度が高くなる
• パッケージファジングの効果
  • バグ検知数はOSS-Fuzz54%、Pkg-Fuzz41%
  • 脆弱性の発見数はそこまで差がない
  • ファジング実行時間についても分析しているが詳細は割愛
  • パッケージファズでも人間が行った場合と同等の効果があることが確認できた
  • ブロック条件や、ファジング実行時間は改善の余地がある
• 攻撃可能性の検証
  • 攻撃可能性があるとはあくまで推定
  • より詳細に分析が必要
  • 実際に制御が行えるかを2ステップで実行
  • ステップ2に非常に時間がかかる
• Step1 ユースケース分析
  • 攻撃実現可能性の低いものを除外
  • 65件から22件に絞り込み
• Step2 エクスプロイトコード分析
  • デバッカなどを使用し手動でエクスプロイトコードを作成
  • 4件の検知
  • スタックバッファオーバーフロー2件
  • ヒープオーバーフロー2件
• 脆弱性の例：Assimp（CVE-2024-40724）
• Demoを実施
• 脆弱性レポート
  • 開発者への報告をIPAやJPCERT/CC経由で実施
  • 1～3か月程度かかる
  • 関係者の方に感謝申し上げる
• 今後の課題
  • 一部の自動化阻害要因を解消したが、まだ解消が必要な部分がある
  • ハーネスジェネレーション
    • 現状対象外としているものがあり、プログラムの作成が必要
    • LLMを活用したアプローチも検討中
  • RootCasuseAnalytics
    • クラッシュしたプログラムのコードを呼んで手動で調査している
    • クラッシュするしないの内部状態の統計的なアプローチなどを検討中
    • 実用上の課題を抱えているので改善中
• RCAツールでの分析を調査した
  • 成功例：sdopだと原因箇所をピンポイントに特定
  • 失敗例：assimpだと正確な特定はできなかった。クラッシュ時と非クラッシュ時の両方で解析されたためと思われる

感想

• 今までリーチできなかった小規模なOSSプロジェクトに貢献するとても意義のある取り組みだと感じました
• 自動化阻害要因を分類してそれぞれ対策する考え方は自社の課題でも多くに当てはまりそうです